A storage system is a computer that provides storage service relating to the organization of information on writeable persistent storage devices, such as memories, tapes or disks. The storage system is commonly deployed within a storage area network (SAN) or a network attached storage (NAS) environment. When used within a NAS environment, the storage system may be embodied as a file server including an operating system that implements a file system to logically organize the information as a hierarchical structure of directories and files on, e.g. the disks. Each “on-disk” file may be implemented as a set of data structures, e.g., disk blocks, configured to store information, such as the actual data for the file. A directory, on the other hand, may be implemented as a specially formatted file in which information about other files and directories are stored.
The storage system may be further configured to operate according to a client/server model of information delivery to thereby allow many client systems (clients) to access shared resources, such as files, stored on the storage system. Sharing of files is a hallmark of a NAS system, which is enabled because of semantic level of access to files and file systems. Storage of information on a NAS system is typically deployed over a computer network comprising a geographically distributed collection of interconnected communication links, such as Ethernet, that allow clients to remotely access the information (files) on the file server. The clients typically communicate with the storage system by exchanging discrete frames or packets of data according to pre-defined protocols, such as the Transmission Control Protocol/Internet Protocol (TCP/IP).
In the client/server model, the client may comprise an application executing on a computer that “connects” to the storage system over a computer network, such as a point-to-point link, shared local area network, wide area network or virtual private network implemented over a public network, such as the Internet. NAS systems generally utilize file-based access protocols; therefore, each client may request the services of the storage system by issuing file system protocol messages (in the form of packets) to the file system over the network. By supporting a plurality of file system protocols, such as the conventional Common Internet File System (CIFS), the Network File System (NFS) and the Direct Access File System (DAFS) protocols, the utility of the storage system may be enhanced for networking clients.
A SAN is a high-speed network that enables establishment of direct connections between a storage system and its storage devices. The SAN may thus be viewed as an extension to a storage bus and, as such, an operating system of the storage system enables access to stored information using block-based access protocols over the “extended bus.” In this context, the extended bus is typically embodied as Fibre Channel (FC) or Ethernet media adapted to operate with block access protocols, such as Small Computer Systems Interface (SCSI) protocol encapsulation over FC (FCP) or TCP/IP/Ethernet (iSCSI). A SAN arrangement or deployment allows decoupling of storage from the storage system, such as an application server, and some level of storage sharing at the application server level. There are, however, environments wherein a SAN is dedicated to a single server. When used within a SAN environment, the storage system may be embodied as a storage appliance that manages data access to a set of disks using one or more block-based protocols, such as SCSI embedded in Fibre Channel (FCP). One example of a SAN arrangement, including a multi-protocol storage appliance suitable for use in the SAN, is described in U.S. patent application Ser. No. 10/215,917, entitled MULTI-PROTOCOL STORAGE APPLIANCE THAT PROVIDES INTEGRATED SUPPORT FOR FILE AND BLOCK ACCESS PROTOCOLS, by Brian Pawlowski, et al.
It is advantageous for the services and data provided by a storage system, such as a storage appliance, to be available for access to the greatest degree possible. Accordingly, some storage systems provide a plurality of storage appliances in a cluster, with a property that when a first storage appliance fails, the second storage appliance (“partner”) is available to take over and provide the services and the data otherwise provided by the first storage appliance. When the first storage appliance fails, the second partner storage appliance in the cluster assumes the tasks of processing and handling any data access requests normally processed by the first storage appliance. One such example of a storage appliance cluster configuration is described in U.S. patent application Ser. No. 10/421,297, entitled SYSTEM AND METHOD FOR TRANSPORT-LEVEL FAILOVER OF FCP DEVICES IN A CLUSTER, by Arthur F. Lent, et al. An administrator may desire to take a storage appliance offline for a variety of reasons including, for example, to upgrade hardware, etc. In such situations, it may be advantageous to perform a user-initiated takeover operation, as opposed to a failover operation. After the takeover operation is complete, the storage appliance's data is serviced by its partner until the partner transfers control back to the storage appliance.
In certain known storage appliance cluster configurations, the transport medium used for communication between clients and the cluster is Fibre Channel (FC) cabling utilizing the FCP protocol for transporting data. In SCSI terminology, clients operating in a SAN environment are initiators that initiate requests and commands for data. The multi-protocol storage appliance is thus a target configured to respond to the requests issued by the initiators in accordance with a request/response protocol. According to the FC protocol, initiators and targets have three unique identifiers, a Node Name, a Port Name and a Device Identifier. The Node Name and Port Name are worldwide unique, e.g. World Wide Node Name (WWNN) and World Wide Port Name (WWPN). A Device Identifier is unique within a given FC switching fabric and is assigned dynamically to the FC port by a FC switch coupled thereto.
In conventional failover techniques involving clusters of storage appliances, each storage appliance in the cluster maintains two physical FC ports, namely an A port and a B port. The A port is utilized for processing and handling data access requests directed to the storage appliance. The B port typically is in a standby mode; when a failover situation occurs, the B port is activated and “assumes the identity” of its failed partner storage appliance. At that point, the B port functions as a FC target to receive and handle data access requests directed to the failed storage appliance. In this way, the surviving storage appliance may process requests directed to both the storage appliance and its failed partner storage appliance. Such a conventional FC failover is further described in the above-referenced patent application entitled SYSTEM AND METHOD FOR TRANSPORT-LEVEL FAILOVER OF FCP DEVICES IN A CLUSTER.
Typically, a port of a “surviving” storage appliance assumes the identity of its failed partner storage appliance by servicing data access requests direct to a WWNN and a WWPN of the partner. For many client operating systems, this is sufficient to permit clients to transparently access the surviving storage appliance as if it were the failed storage appliance. After the surviving storage appliance assumes the identity of the failed storage appliance, data access requests directed to the network address of the failed storage appliance are received and processed by the surviving storage appliance. Although it may appear to the clients as if the failed storage appliance was momentarily disconnected and reconnected to the network, data operations or data access requests continue to be processed.
FIG. 1 is a schematic block diagram of an exemplary storage (appliance) system network environment 100. The environment 100 comprises a network cloud 102 coupled to a client 104. The client 104 may be a general-purpose computer, such as a PC or a workstation, or a special-purpose computer, such as an application server, configured to execute applications over an operating system that includes block access protocols. A storage system cluster 130, comprising Red Storage System 200A and Blue Storage System 200B, is also connected to the cloud 102. These storage systems are illustratively embodied as storage appliances configured to control storage of and access to interconnected storage devices, such as disks residing on disk shelves 112 and 114.
In the illustrated example, Red Storage System 200A is connected to Red Disk Shelf 112 by it's A port 116. The Red Storage System 200A also accesses Blue Disk Shelf 114 via its B port 118. Likewise, Blue Storage System 200B accesses Blue Disk Shelf 114 via A port 120 and Red Disk Shelf 112 through B port 122. Thus each disk shelf in the cluster is accessible to each storage appliance, thereby providing redundant data paths in the event of a failover. It should be noted that the Red and Blue disk shelves are shown directly connected to the storage systems 200 for illustrative purposes only.
Connecting the Red and Blue Storage Systems 200A, B is a cluster interconnect 110, which provides a direct communication link between the two storage systems. The cluster interconnect 110 can be of any suitable communication medium, including, for example, an Ethernet connection or a FC data link.
During normal cluster operation, the storage system that is connected to a disk shelf via the disk shelf's primary (i.e., A) port is the “owner” of the disk shelf and is primarily responsible for servicing data requests directed to blocks on volumes contained on that disk shelf. Thus, in this example, the Red storage system 200A owns the Red Disk is Shelf 112 and is primarily responsible for servicing data access requests for blocks contained on that disk shelf. Similarly, the Blue storage system 200B is primarily responsible for the Blue disk shelf 114. When operating as storage system cluster 130, each storage system 200 is typically configured to take over and assume data handling capabilities for the other disk shelf in the cluster 130.
A known storage system architecture provides the ability to create and maintain multiple instances of block-based virtual servers, such as virtual storage systems (vfilers), within a single physical server, such as a physical storage system platform. Vfilers are further described in U.S. patent application Ser. No. 10/035,664, entitled ARCHITECTURE FOR CREATING AND MAINTAINING VIRTUAL FILERS ON A FILER, by Mark Muhlestein, et al. Each vfiler is maintained and executed entirely independent of other vfilers on the platform. To that end, dedicated storage system resources, such as units of storage and network addresses of network interfaces, may be arbitrarily grouped and “hard” partitioned to establish security domains within the storage appliance. Yet common storage system resources, such as a storage operating system and a file system, may be shared among the vfilers.
A noted problem with storage environments having a plurality of physical storage systems, each with one or more vfilers executing thereon, is that the processing load on the physical storage systems may become imbalanced due to, for example, a vfiler experiencing higher than average load. Should several vfilers executing on a single physical storage system experience higher than average load, the physical storage system will suffer decreased performance, thereby adversely affecting the performance of each of the vfilers executing therein. Conventional vfiler migration may be utilized, for example, by a system administrator to attempt to redistribute the load. Conventional vfiler migration is further described in U.S. patent application Ser. No. 10/098,814, entitled REMOTE DISASTER RECOVERY AND DATA MIGRATION USING VIRTUAL APPLIANCE MIGRATION, by Wesley R. Witte, et al. However, typical load balancing techniques require an administrator to detect the over balanced vfiler and to take corrective action by initiating a migration.